This is a documentation-only deprecation for now.
Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to
  compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the
necessary mechanisms for environmental or persistent configuration (e.g.
using cargo config which supports `.cargo/config.toml` as well as
environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to
  implement
- Reduce the mechanisms that test runners, like `cargo test`, are
  expected to track when they are being bypassed to protect against
  negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output
  is being read.

Signed-off-by: Sacha Ayoun <[email protected]>

chore(ci): upgrade checkout to v5

…ross35

Add ASCII-related methods from `u8` and `MIN`/`MAX` to `core::ascii::Char`

* Add ASCII-related methods from `u8` to `core::ascii::Char`.
* Add `core::ascii::Char::MIN` and `core::ascii::Char::MAX`.

…hpratt

Constify `SystemTime` methods

This is separated out from rust-lang#143949 due to the fact that it touches nontrivial system code. While the same arithmetic methods on `Instant` could be made const, since that type explicitly cannot be constructed at const-time, we don't bother. However, due to the fact that `SystemTime::UNIX_EPOCH` exists, it can be useful to create other anchors at other points in time, and thus these methods should be possible to use in const context.

> Side comment: I would honestly like to just move every single implementation which is a thin wrapper over `Duration` or some integer clock into their own module which is tested on all targets, so that we don't have to worry about code for lower-tier targets not being tested. However, the comments in `std::sys_common` pointing out the desire to move things to `std::sys::common` confused me, particularly due to the fact that `std::sys::common` is taken from the hellish asterisk-import of `std::sys::pal::common` and others.
>
> I think that, for trivial types like this, we should just have a platform-independent module that can be tested on all platforms, to both ensure that the code is properly tested regardless of whether higher-tier platforms needed, and to avoid the extreme mental gymnastics required to determine where in the code it lies.
>
> However, since I'm not on any of the teams maintaining this code and am not involved, I'll settle for just copy-pasting like everyone else has been doing. I just want to express how I'm not happy about that.

**Reviewer note: please only pay attention to the last commit of this PR, until its blocker is merged.**

Since this depends on the previous PR:
`@rustbot` blocked

…ake, r=lcnr

editorconfig: don't trim trailing whitespace in tests

some test snapshot files require trailing whitespace, and previously manually editing those snapshot files (as is required for run-make tests and some platform-specific tests) in an editor with editorconfig support would cause that whitespace to be removed, [causing CI failures like this one](rust-lang#144596 (comment))

…gross35

Stabilize `path_file_prefix` feature

This stabilises `Path::file_prefix`, following the FCP in [tracking issue ](rust-lang#86319)

(FCP ended almost a year ago, so if it's needed for proccess we could rerun it)

Closes: rust-lang#86319

Deprecate RUST_TEST_* env variables

Like with rust-lang#139224, this is a documentation-only deprecation for now. Over time, we can
- warn and then remove on use of unstable environment variables
- warn on use of stable environment variables (no plan to remove due to compatibility)

Longer term, we expect test runners, like `cargo test`, to provide the necessary mechanisms for environmental or persistent configuration (e.g. using cargo config which supports `.cargo/config.toml` as well as environment variables).

This would include:
- `RUST_TEST_THREADS`
- `RUST_TEST_NOCAPTURE`
- `RUST_TEST_SHUFFLE` (unstable)
- `RUST_TEST_SHUFFLE_SEED` (unstable)

The primary outcomes for this change are
- Reducing the scope of what is expected for custom test harnesses to implement
- Reduce the mechanisms that test runners, like `cargo test`, are expected to track when they are being bypassed to protect against negative interactions, e.g.  `RUST_TEST_NOCAPTURE=1` when json output is being read.

For testing-devex FCP, see rust-lang/testing-devex-team#10

Fixes rust-lang/testing-devex-team#10

History
-------

At each step, I could not find evidence of design discussions on whether to support CLI, env, or both.  The first env variable seems to come from the fact that it was being forked out of an existing env variable that had a much wider scope.

At best, this seems like a way to offer a more persistent configuration for these flags but environment variables hidden away in libtest is a bit clunky and this seems like the wrong layer to handle this problem.

**Originally:** `RUST_THREADS` was respected by the Rust runtime and libextra/test got this for free

**2013:** rust-lang#7335 suggested splitting `RUST_TEST_TASKS` out of `RUST_THREADS`.  In that issue and the implementation (rust-lang#8823).

**2014:** rust-lang#13374 ask for support to disable capturing of stdout/stderr.  `--nocapture` and `RUST_TEST_NOCAPTURE` were added together.

**2015:** rust-lang#23525 renamed `RUST_TEST_TASKS` to `RUST_TEST_THREADS`

**2016:** rust-lang#25636 asked to configure `RUST_TEST_THREADS` via `--test-threads` which was implemented in rust-lang#35414

**2021:** rust-lang#85440 asked for test randomization which was implemented in rust-lang#89082, adding `--shuffle` / RUST_TEST_SHUFFLE` and `--shuffle-seed SEED` / `RUST_TEST_SHUFFLE_SEED`

Potentially relevant issues
---------------------------

- rust-lang#74845

…=fmease

Remove unused `#[must_use]`

Self-explanatory

Fixes rust-lang#145257

chore(ci): upgrade checkout to v5

Maintenance update to actions/checkout@v5 to align with the current runner stack (Node 24); nothing else modified.

Release notes: https://github.com/actions/checkout/releases/tag/v5.0.0

Docs: Link to payload_as_str() from payload().

Adjust documentation of `dangling`

I believe the current doc of `dangling` is slightly off as it indicates:
`Note that the pointer value may potentially represent a valid pointer to a T`

The returned pointer has no provenance, so it may not be a valid pointer (except in the case of ZSTs, but I don't think this is what the documentation is trying to warn about).

See: https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Dangling.20pointers.3A.20definition

The value returned by dangling may never be used to dereference a value that isn't a ZST, even if address equality is detected with that of a valid pointer.
This is a minor fix, but this doc still got me confused for a second

… r=shepmaster

Allow cross-compiling the Cranelift dist component

Should help unblock rust-lang#145252 (https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/macos-13.20shutting.20down/with/534032174).

Add `cast_init` and `cast_uninit` methods for pointers

ACP: rust-lang/libs-team#627
Tracking issue: rust-lang#145036

This includes an incredibly low-effort search to find uses that could be switched to using these methods. I only searched for `cast::<\w>` and `cast::<MaybeUninit` because there would otherwise be way too much to look through, and I also didn't modify anything inside submodules/subtrees.